docs(api-development): add error handling guide - #111
Merged
Conversation
Document the standard error response envelope for Nerva APIs: the error code registry and constants pattern, typed AppError classes, global handling via app.onError() and app.notFound(), per-category examples (400/401/403/404/409/429/500), and the mapping to RFC 9457 Problem Details. Update the standards README to the nested envelope shape and link the guide. Closes #56 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds
docs/api-development/error-handling.md-- the standard error response format guide for Nerva APIs (issue #56). Every endpoint returns errors as a single top-levelerrorobject inside the envelope defined in.claude/pipeline.config.json.What is covered
{ error: { code, message, details, requestId } }with field-by-field rules (stable codes, prose messages, nothing internal leaks)ErrorCodesconst object with a derivedErrorCodeunion typeAppErrorbase plusNotFoundError/ConflictError/UnauthorizedError/ForbiddenError, typed withContentfulStatusCodeso the handler compiles without castsapp.onError()covering ZodError, AppError, HTTPException (sohono/jwt401s andbodyLimit413s do not surface as 500s), and the unexpected-error fallback;app.notFound()for unmatched routes; request-id wiringapplication/problem+jsonif a consumer requires it{ error: ..., code: ... }shape), gains thePAYLOAD_TOO_LARGErow, and links the guide from both error-handling sectionsAcceptance criteria
docs/api-development/error-handling.mdcreatedapp.onError()global handling showndocs/api-development/README.mdFollow-up worth noting
The
route-generationandapi-validationskills currently emit validation details as{ path, message, code }, while the standard (this guide, issue #56,brand-guardian,error-boundary-architect, and the TDD helpers) uses{ field, message }. A small follow-up could align those two skills with the documented standard.Closes #56
🤖 Generated with Claude Code